Computer systems use stacks which may be registers or memory blocks where data is stored and retrieved in a particular fashion (e.g., last in first out or first in first out). The operating system (OS) within the computer system may manage numerous stacks, interrupt stacks, kernel stacks, thread stacks, user stacks, etc. Some stacks in a computer system are fixed in hardware (e.g., fixed register stacks) and others are merely memory allocations (stack memory) wherein a block of memory is defined as a stack whose size and the location may be variable. A fixed register stack is easier to manage since the size is known and simple techniques of adding and subtracting entries from a counter give an indication of the availability of locations within the register stack for storing data. When a stack may be variable in size and location then, it may prove difficult to manage the stack memory along with other necessary memory allocation management without wasting (by blocking access) memory space.
Some computer architectures (e.g., Intel IA64) have begun to use multiple variable stacks per execution context compounding the problem of managing the variable stacks within the other memory management requirements. Within stack memory (memory designated by the operating system only for stack use) there have traditionally been two types of stacks, a “program stack” and a “processor stack” (e.g., an IA64 register stack). The program stack is the “traditional” run-time stack where the program saves/restores hardware register data. The processor stack is a new additional run-time stack required by some computer architectures (e.g., IA64) so the processor can save/restore hardware register data, however these stacks may be transparent to a compiler or a programmer. The operating system (OS) maintains tables of available memory for the processor to use as a processor stack. The main difference between the program stack and the processor stack is that the program stack is used by the compiler for procedural local data and the processor stack is used by the processor for stacked register data (essentially making the registers a cache of recently used, current context registers) and may be transparent to a programmer (e.g., in IA64).
One of the classic issues in managing stack memory is how to protect against a stack over run or under run. Traditionally, protection against an over run or an under run has been solved by allocating “red zones” or protected pages in memory. These protected pages were set up to cause a fault when an over run or under run occurs. The problem (which may be compounded with multiple variable stacks per execution context) in some computer architectures (e.g., IA64) is that pages are wasted in the requirement to set up the “red zones” or protected pages for every stack in the system. Also of concern is the fact that “red zones” do not always work, for example, a stack pointer may be decremented an amount greater than a “page size” and effectively skip over the protected page or “red zone”. Likewise, the future use of multiple variable stacks per execution context (e.g., IA64) may create stacks that are potentially transparent to the compiler or programmer. Of particular concern are operations within these variable program stacks where information is corrupted without a corresponding error condition being signaled so that error correction techniques would enable recovery.
There is therefore a need for a system and method for managing stack memory that prevents stack corruption without there being appropriate recovery in place.